The invention relates generally to computer systems, and more particularly to a technique to manage a communication session.
It is known for two computers to establish a communication “session” between themselves and then communicate with each other in the session using TCP protocol. A “session” is an association of facilities necessary for establishing, maintaining and releasing connections for communication between two computers. For example, each computer typically assigns a message inbound socket and a message outbound socket for the session. A “socket” is a combination of IP address and port. To establish the session, an initiating computer typically sends a request to a destination computer to “open” the session, such as a standard TCP function connect. (The open request can be sent to an IP address and port of the server.) The destination computer which performs server functions listens for requests on a particular socket. That request is handled by the operating system. From the operating system standpoint that socket is a passive socket and it is function of the operating system to accept incoming connections requests on it. Upon receipt of a new open (connection) request, the operating system within the destination computer will determine that this is a request for a new session and put the request into a queue. All those connections/sessions are considered incomplete until an application program on the destination computer issues a TPC function “accept” to get the connection request from the queue and complete the connection. The destination computer operating system keeps track of all subsequent requests within the session which is established. The destination computer will also assign an unused outbound socket for all responses to the initiating computer for this session. The destination computer will also send to the initiating computer an acknowledgment (with the session ID) to indicate that the session request has been accepted. The initiating computer will use a socket which it previously assigned to this session to receive the acknowledgment. After receipt of the acknowledgment, the initiating computer can send to the destination computer an operational request (with the session ID) to read or write data, access a web application or for another service. In the case of a read request, the operational request typically includes an identity (or address range) of a file to be read. In the case of a write request, the operational request typically includes an identity (or address range) of a file to be written and data to be written to the file in the destination computer. In the case of a read request, the destination computer will typically respond to the initiating computer with the requested data, and in the case of a write request, the destination computer will typically respond to the initiating computer with an acknowledgment that the data has been successfully written. After the requested operation is completed and the initiating computer has no more requests for this session, the initiating computer will typically send a request to the destination computer to “close” the session. The “close” request can be recongnized by recieving s special error code when attempting to perform an I/O operation within the session, i.e. inability to perform further reading because the socket is closed. Upon receipt of the “close” request, the destination computer will delete the session ID from its list of active sessions and terminate the assignment of its inbound and outbound sockets to this session so that these inbound and outbound sockets can be used for other sessions. Also, after closing the session, the destination computer will typically send an acknowledgment to the initiating computer that the session has been closed. At such time, the initiating computer will delete the session ID from its list of active sessions and terminate the association of its inbound and outbound sockets to the session so they can be used for another session.
In a client/server arrangement, typically the client is the initiating computer and the server is the destination computer. The client initiates the session to obtain a service from the server, such as to read data which has been backed up or otherwise stored by the server, to backup data or otherwise store data at the server or to request a service by an application hosted by the server. Such services may include web services, or any other TCP service such as remote database connectivity. In the case where the destination server hosts a web or other application, there may be a proxy server which receives the client request on behalf of the destination server and forwards the client request to the destination server which provides the requested service.
In most cases, the open request, associated operational request with request parameters (for example, in the case of a read request the identity or address range of a file to be read, in the case of a write request the identity or address of a file to be written and the data to be written, in the case of a request for a web application, the URL or other address of a web page representing the interface to the application, and in the case of a database remote connect request, database response and associated close request are sent in separate messages. In addition, if the data of a write request is lengthy, multiple messages may be required to transfer the data. However, in other cases where the communication protocol permits and the amount of data to be written is short or in the case of another operational request which does not require transmission of lengthy data, the “open” request, associated operational request with request parameters and associated “close” request may all be sent in one message.
A problem with known systems is that a destination computer often receives an “open” request in one message, but not any related operational request or request parameters in the same or subsequent message. This may be caused by a legitimate problem with the initiating computer or communication path between the initiating computer and destination computer or by a malicious denial of service attack. In such cases, the destination computer incurs the overhead of opening the session and “ties-up” two sockets, but accomplishes nothing productive. A large number of such unproductive open requests can seriously burden the destination computer and degrade the response time to productive requests.
Accordingly, an object of the present invention is to better manage sessions to avoid the foregoing problem.